Maintaining triggered session state in secure user plane location (supl) enabled system

ABSTRACT

A method is provided for maintaining session state in a Secure User Plane Location (SUPL) enabled system during a triggered session. The method includes modifying at least one parameter of a session message to include state data indicating the session state, and transmitting a request to a SUPL Enabled Terminal (SET) to initiate the triggered session, the request comprising the session message having the at least one modified parameter to be stored at the SET. The method further includes receiving a triggered message from the SET in response to occurrence of a trigger event detected by the SET, the triggered message comprising the stored state data. The triggered session is identified using the state data received in the triggered message.

RELATED APPLICATIONS

This application is a continuation application of pending U.S.application Ser. No. 13/101,243 filed 5 May 2011, which claims priorityfrom expired Provisional Application Ser. No. 61/348,788, filed 27 May2010, in the United States Patent and Trademark Office, both of whichare hereby incorporated by reference in their entirety as set forthherein.

BACKGROUND AND SUMMARY

This disclosure generally relates to location services in variouswireless communication systems, such as Global System for Mobilecommunication (GSM), Code Division Multiple Access (CDMA), and UniversalMobile Telecommunication System (UMTS) networks. Further, thisdisclosure relates to user plane location approaches in core networksand complementary access networks.

Network operators are increasingly providing location services fordetermining estimated geographic locations or positions of mobiledevices, such as cellular telephones, personal digital assistants(PDAs), and the like. Location determination may be performed, forexample, using positioning measurements from Global Navigation SatelliteSystem (GNSS) satellites (for mobile devices equipped with GNSSreceivers) and/or terrestrial positioning systems. GNSS includes anysatellite positioning system configured to provide geographic locationsof receivers using a constellation of satellites, such as GlobalPositioning System (GPS), Global Navigation Satellite System (GLONASS),Galileo and COMPASS Navigation Satellite System (BeiDou). Terrestrialpositioning systems may be based on any type of range measurements, suchas uplink-time difference of arrival (U-TDOA) or timing advance (TA)measurements (e.g., in GSM networks), round-trip time (RTT) measurements(e.g., in UMTS networks), enhanced observed time difference (E-OTD)measurements, angle of arrival (AoA) measurements, power of arrival(POA) measurements, WiFi measurements, DTV signals and the like.

The estimated location of a mobile device may be determined based oncertain predetermined conditions, referred to as “conditional triggers.”Conditional triggers may correspond to occurrence of various triggerevents, such as the mobile device entering or leaving a specified area,or the passing of a specified period of time. Position data is thenprovided by the mobile device and/or the location of the mobile deviceis determined upon occurrence of one or more of the trigger events.

Various protocols have been developed to enable communication withmobile devices, including Secure User Plane Location (SUPL) protocol ofthe Open Mobile Alliance (OMA), as described, for example, in “SecureUser Plane Location Architecture,” Candidate Version 2.0,OMA-AD-SUPL-V2.sub.--0-20091208-C (Dec. 8, 2009), the subject matter ofwhich is hereby incorporated by reference. SUPL provides locationservices through the user plane, enabling the transfer of position datafrom a mobile device, referred to as a SUPL Enabled Terminal (SET), overa user plane bearer, such as internet protocol (IP), for determinationof the geographical location of the SET. The SUPL protocol defines aLocation User Plane (Lup) Reference Point and corresponding interfacebetween a SUPL Location Platform (SLP) and the SET, as well as varioussecurity and privacy functions. A UserPlane Location Protocol (ULP) is aprotocol-level instantiation of the Lup Reference Point, used betweenthe SLP and the SET, as described, for example, in “UserPlane LocationProtocol,” Draft Version 2.0, OMA-TS-ULP-V2.sub.--0-20100429-D (Apr. 29,2010), the subject matter of which is hereby incorporated by reference.

SUPL enables a client of a location service to request notification ofthe location of a SET in response to conditional triggers, as discussedabove. For example, a conditional trigger may correspond the SETentering or leaving a specified region or occurrence of a specified timeor time interval. As discussed above, the location of the SET may bedetermined, for example, by a server or other network node, usingpositioning measurements from GNSS satellites received by a GNSSreceiver of the SET, and/or using positioning measurements fromterrestrial positioning systems. Generally, the SLP is responsible forestablishing and maintaining the conditional triggers in the SET, whichthen acts autonomously to detect the trigger events that meet theconditions of the conditional triggers. Once a trigger event isdetected, the SET contacts the SLP, the position of the SET isdetermined, and the location client is notified of the location of theSET.

Conventional SUPL designs require one or more SLP nodes of the SLP tomaintain the state necessary to identify the triggered session and toimplement the conditional trigger and corresponding locationdetermination. Since the SLP manages numerous SETs, the SLP mustmaintain numerous corresponding triggered session states. Even withmodern storage capacities, this represents a challenge for the SLP fromthe state persistence perspective.

In a representative embodiment, a method is provided for maintainingsession state in a Secure User Plane Location (SUPL) enabled systemduring a triggered session. The method includes modifying at least oneparameter of a session message to include state data indicating thesession state; transmitting a request to a SUPL Enabled Terminal (SET)to initiate the triggered session, the request including the sessionmessage having the at least one modified parameter to be stored at theSET; and receiving a triggered message from the SET in response tooccurrence of a trigger event detected by the SET, the triggered messageincluding the stored state data. The triggered session is identifiedusing the state data received in the triggered message.

In another representative embodiment, a computer readable medium isprovided for storing code executable by a computer processor formaintaining session state in a SUPL enabled system during a triggeredsession. The computer readable medium includes modifying code segment,transmitting code segment, receiving code segment, and identifying codesegment. The modifying code segment is for modifying at least oneparameter of a session message to include state data indicating thesession state. The transmitting code segment is for enablingtransmission of a request to a SET to initiate the triggered session,the request including the session message having the at least onemodified parameter to be stored at the SET. The receiving code segmentis for receiving a triggered message from the SET in response tooccurrence of a trigger event detected by the SET, the triggered messageincluding the stored state data. The identifying code segment is foridentifying the triggered session using the state data received in thetriggered message.

In another representative embodiment, a method is provided formaintaining session state in a SUPL enabled system during a triggeredsession, without a SUPL Location Platform (SLP) maintaining statenecessary to identify the triggered session, The method includes settingfree bits of a SlpSessionID parameter in a session message to includestate data indicating the session state; transmitting the sessionmessage to a SUPL Enabled Terminal (SET) to initiate the triggeredsession, the SET storing the free bits of the SlpSessionID; receiving aSUPL POS INIT message from the SET upon occurrence of a trigger event toinitiate position determination as part of the triggered session, theSUPL POS INIT message comprising the stored state data; identifying thetriggered session using the stored state data in the SUPL POS INITmessage; and exchanging SUPL POS messages with the SET, with at leastone SUPL POS message including position data indicating a location ofthe SET. An estimated position of the SET is calculated using theposition data in the SUPL POS message.

BRIEF DESCRIPTION OF THE DRAWINGS

The illustrative embodiments are best understood from the followingdetailed description when read with the accompanying drawing figures. Itis emphasized that the various features are not necessarily drawn toscale. In fact, the dimensions may be arbitrarily increased or decreasedfor clarity of discussion. Wherever applicable and practical, likereference numerals refer to like elements.

FIG. 1 is a call flow diagram illustrating a procedure for establishingand maintaining a triggered session for location determination of amobile device based on a conditional trigger, according to arepresentative embodiment.

FIG. 2 is a block diagram showing an illustrative format of state datain which the data is encrypted, according to a representativeembodiment.

FIG. 3 is a block diagram showing an illustrative format of state datain which the data is not encrypted, according to another representativeembodiment.

FIG. 4 is a flowchart illustrating a method for establishing andmaintaining a triggered session for location determination of a mobiledevice based on a conditional trigger, according to a representativeembodiment.

FIG. 5 is a functional block diagram illustrating a processing devicefor establishing and maintaining a triggered session for locationdetermination of a mobile device based on a conditional trigger,according to a representative embodiment.

DETAILED DESCRIPTION

In the following detailed description, for purposes of explanation andnot limitation, illustrative embodiments disclosing specific details areset forth in order to provide a thorough understanding of embodimentsaccording to the present teachings. However, it will be apparent to onehaving had the benefit of the present disclosure that other embodimentsaccording to the present teachings that depart from the specific detailsdisclosed herein remain within the scope of the appended claims.Moreover, descriptions of well-known devices and methods may be omittedso as not to obscure the description of the example embodiments. Suchmethods and devices are within the scope of the present teachings.

FIG. 1 is a call flow diagram illustrating a procedure for establishingand maintaining a triggered session for location determination of amobile device based on a conditional trigger, according to arepresentative embodiment.

Referring to FIG. 1, wireless communications network 100 has SUPLarchitecture, and includes location client 110, SUPL Location Platform(SLP) 120 and representative SUPL Enabled Terminal (SET) 130. Thelocation client 110 may be a location server, for example, implementedby a third party, such as a network operator or a service provider. Invarious illustrative implementations, the location client 110 may beincluded a mobile location center (MLC) server in the wirelesscommunication network, such as a gateway mobile location center (GMLC)or a serving mobile location center (SMLC) in a GSM network or astand-alone SMLC (SAS) in a UMTS network, for example. The SET 130 is amobile device, such as a cellular telephone, a PDA, a laptop or otherportable computer, or the like. In various implementations, the locationclient 110 may be included in the SET 130, in which case the SET 130requests and receives its own location, e.g., in response to conditionaltriggers.

In the depicted embodiment, the SLP 120 includes clustering of multiplenodes for scaling and availability purposes, such that a load-balancingsystem distributes incoming requests to individual nodes. The multiplenodes are depicted as representative SLP nodes 121-123, each of whichmay process a subset of requests. The SLP nodes 121-123 may be separateservers, e.g., grouped at a single location or distributed over separategeographic locations to cover different territories. For example, theSLP nodes 121-123 may be co-located with a GMLC in the 3GPP corenetwork; an SMLC, base stations and/or a base station controller (BSC)in a GSM network or with a SAS, Node Bs and/or a radio networkcontroller (RNC) in a UMTS network.

At step 101 in FIG. 1, the location client 110 initiates a session withthe SET 130 through the SLP node 121 of the SLP 120, which may be ahome-SLP (H-SLP) or a visited-SLP (V-SLP). The session may be a“triggered session,” according to which the location client 110 requeststriggered reports of the location of the SET 130 based on one or moreconditional triggers. For example, in order to initiate the triggeredsession, the location client 110 may send a mobile location protocol(MLP) triggered location reporting request (tlrr) to the SLP node 121,identifying the SET 130 and specifying one or more conditional triggers.The SLP node 121 may authenticate the location client 110 and determinewhether it is authorized for the requested triggered session. Theconditional trigger may be location based, where the correspondingtrigger event is the SET 130 leaving or entering a particular geographicregion. Also, the conditional trigger may be time based, where thecorresponding trigger event is a time of day or a predetermined timeinterval. Other types of conditional triggers may be implemented, andmore than one conditional trigger may be specified, without departingfrom the scope of the present teachings. Although FIG. 1 depicts thetriggered session being initiated through the SLP node 121, for purposesof illustration, it is understood that the triggered session may beinitiated through any one of the SLP nodes 121-123, depending on variousfactors, such as the respective work load of the SLP nodes 121-123, thegeographic location of the location client 110 and/or the SET 130,available memory, and the like. As mentioned above, a load-balancingsystem may perform the distribution among the SLP nodes 121-123.Notably, the location client 110 and/or the SET 130 may perform loadbalancing themselves in different ways, but a highly available loadbalancer may be incorporated.

The SLP node 121 initiates the triggered session with the SET 130 atstep 102. For example, the SLP node 121 may send a SUPL INIT message tothe SET 130, identifying the location client 110 and specifying theconditional trigger. In an embodiment, a handshake may be performed (notshown) between the SET 130 and the SLP node 121. For example, the SET130 may send a SUPL TRIGGERED START message to the SLP node 121 to startthe triggered session, and the SLP node 121 may respond with a SUPLTRIGGERED RESPONSE message.

Once the triggered session has been initiated, the SET 130 monitors foroccurrence of the trigger event corresponding to the conditional triggerat step 103. For example, the SET 130 may be configured to compare itscurrent position (e.g., by position estimate or presence within aparticular cell) with a target geographic region, so that it is able todetermine when it enters and/or leaves the target geographic regionLikewise, the SET 130 may be able to compare the current time with apredetermined target time of day or time interval.

Once the occurrence of the trigger event is detected, the SET 130 sendsa triggered message to SLP node 123 at step 104. For example, thetriggered message may be a SUPL POS INIT message, which includes theidentity of the SET 130. This occurs when the SET 130 initiates locationdetermination procedures, and accordingly sends a SUPL POS NIT, followedby an exchange of one or more SUPL POS messages, which include positiondata of the SET 130. Alternatively, or in addition, the triggeredmessage may be a SUPL REPORT message, for example, and may include theidentity of the SET 130, the time of occurrence of the trigger event,and the position data. This occurs once a final location of the SET 130has been calculated and the trigger is deemed to have been met.

In the depicted embodiment, the position data include positioningmeasurements that enable the position estimate of the SET 130, at thetime of occurrence of the trigger event, to be calculated by the SLPnode 123 in step 105. For example, when the SET 130 incorporates a GPSreceiver, the position data may include pseudo-ranges measured betweenthe SET 130 and multiple GPS satellites. In an alternative embodiment,the position data may indicate the actual position estimate (geographiclocation) of the SET 130 at the time of occurrence of the trigger event,when the SET 130 has the capability to perform this calculation itself.For purposes of illustration, the SLP node 123 is assumed to be the SLPnode servicing the SET 130 at the time the trigger event occurs,although it is understood that the triggered message may be sent to anyone of the SLP nodes 121-123 with which the SET 130 is able tocommunicate.

As mentioned above, when the triggered message or a message subsequentto the triggered message includes the position data (e.g., SUPL REPORTor SUPL POS messages), the SLP node 123 retrieves the position data fromthe triggered message and calculates the position estimate of the SET130 using any GNSS and/or terrestrial positioning calculation techniqueat step 105. The SLP node 123 sends calculated the position estimate ofthe SET 130 to the location client 110 at step 106. For example, the SLPnode 123 may send an MLP triggered location report (fir) to the locationclient 110, which includes the position estimate.

Sending the position estimate does not necessarily end the triggeredsession, as multiple trigger events may occur over an extended triggeredsession. For example, the triggered session may be a long running orextended triggered session (e.g., up to 100 days). Between occurrencesof trigger events, the communication channel between SET 130 and the SLP120 may be closed to preserve resources. Either the SET 130 or the SLP120 may resume communications related to the long running triggeredsession. For example, a 32-bit identifier, referred to as sessionID, maybe used to identify the triggered session when resuming communications.

As mentioned above, in accordance with the SUPL protocol, the sessionstate must be maintained both to identify the triggered session and tocontinue the triggered session. Typical session state data is tabulatedin Table 1, below:

TABLE 1 State Maximum Size Information Type (Bytes) Session TypeTriggered/Periodic/Basic/etc. 1 SET identifier Varies, MSISDN (most 8common) is 15 digits Client URL Unconstrained (but can be limited) 100Request ID Constructed by SLP 12 Start Time Date and Time 8 Rate Timeinterval 2 End Time Date and time 8 Report Count Integer 2 Max ReportsInteger 2 SPUL INIT HMAC 64 bits from 256-bit output of 8 HMAC functionusing SHA-256 Total Size 151

Conventionally, the SET 130 maintains state only for a small number ofits own triggered sessions, so its state data does not represent asignificant imposition on even limited resources. On the other hand, theSLP 120 maintains triggered session states for a large number of SETs,including the SET 130. For example, for triggered sessions to work, allof the SLP nodes 121-123 in the SLP 120 must have access to the statedata necessary to continue the triggered session. The load balancingsystem could be given sufficient information to redirect requests in away that ensures that requests for the same triggered session are alwaysdirected to the same servicing SLP node 121-123. However, in a highlyavailable system, the design must allow for failure of current servicingSLP node 121-123 over the lifetime of the triggered session,particularly a long-lived trigger session. Session state may be moved toa shared resource, like a database. However, this may introduce a singlepoint of failure, which would result in all the SLP nodes 121-123 in theSLP 120 being unable to access the necessary state data. Redundant,highly available database systems may avoid this problem, but can becostly and difficult to implement.

Thus, according to various embodiments, to avoid the SLP 120 and/or ashared resource from having to maintain state, the SLP state data isprovided to the SET 130, e.g., when the SLP node 121 initiates thetriggered session with the SET 130 at step 102. The state data includesinformation for establishing and re-establishing communications with theSET 130, such as the SET identifier. The SET 130 stores the state data,along with its own state information.

In order to provide the state data to the SET 130, the SUPL sessionmessaging is modified to include the state data. In an embodiment, everyrequest made in relation to the triggered session shares a number ofparameters, which are echoed verbatim by the SET 130. Nominally, theseparameters are used to provide the SET 130 with the ability to correlatea request with the state data that it stores, but there are sufficientfree bits in the messaging fields which may be used more directly.

Representative parameters of session messaging, e.g., included in theSUPL INIT message sent by the SLP node 121 to the SET 130 in step 102,according to ULP, are as follows:

SlpSessionID : : = SEQUENCE { sessionID OCTET STRING (SIZE (4)),SLPAddress} SLPAddress : : = CHOICE {iPAddress IPAddress, fQDN FQDN,...} FQDN : : = VisibleString (FROM (“a”..”z” ∥ “A”..”Z” ∥ “0”.. ”9” ∥“.—“)) (SIZE (1..255))

As indicated above, the SlpSessionID parameter has a total size of 259characters, and includes a sessionID field and a slpID field. ThesessionID field contains a 32-bit session identifier (ID), indicated asan octet string, which is unique with respect to all concurrently activeULP sessions on the servicing SLP (e.g., one of SLP nodes 121-123), andthe slpID field contains a text string that nominally identifies theservicing SLP. The slpID field is indicated as the SLPAddress parameter,which may include an IP address or fully qualified domain name (FQDN) togive the SLP 120 an easy way of identifying the servicing SLP node121-123 in the cluster, and thus identifies the originator and/orcontroller of a particular triggered session.

The SlpSessionID parameter includes a number of free bits, which are notused in the sessionID field and/or the slpID field. In particular, thereare 64 different possible values for each of the 255 characters of theSlpSessionID parameter, since there are 6 bits per character of freelyusable entropy. If some simple constraints are placed on the state data,the state data can be compressed to fit in the available space. Forexample, modified base64 encoding may be used to fit up to 191.25 bytesof data (255*3/4) in the SLPAddress parameter, or 1,530 bits. An exampleof base64 encoding is described in RFC 4648, “The Base16, Base32, andBase64 Data Encodings,” http://tools.ietf.org/html/rfc4648 (October2006), the subject matter of which is hereby incorporated by reference.Adding the 32 bits of the sessionID field means that there are 195.25bytes of data, or 1,562 bits, available to the SLP 120 for providingstate data to the SET 130 using the SlpSessionID parameter. Although theSlpSessionID parameter is discussed in detail, it is understood thatother parameters and/or fields of ULP may be used to communicate thestate data to the SET 130, and/or to compress or reduce the amount ofstate data, without departing from the scope of the present teachings.

The free bits in the SlpSessionID parameter are set by the SLP 120. Forexample, the SLP 120 may define a fixed structure for the necessarystate data. Based on this structure, bits are extracted six at a timeand converted to a character in the slpID field based on a fixedmapping. For instance, 000000.fwdarw.a, 000001.fwdarw.b,000010.fwdarw.c, etc. The resulting slpID is sent to the SET 130 in step102 of FIG. 1 to cause the SET 130 to store all of the necessary statedata for the triggered session. The SLP 120 itself therefore does nothave to store state data or otherwise maintain state at all. Thenecessary state data is then provided by the SET 130 in the SlpSessionIDparameter in a triggered message in response to a trigger event, whenthe SET 130 subsequently contacts the SLP 120 in step 104 of FIG. 1.

As mentioned above, the SET 130 may exchange positioning messages (e.g.,SUPL POS messages) with the SLP 120 prior to sending a triggered report(e.g., between steps 102 and 103), where the positioning messageslikewise contain the SlpSession ID parameter, and thus the state dataencoded therein. Also, when the SLP 120 is clustered, as shown in FIG.1, it no longer matters which SLP node (e.g., SLP nodes 121-123) servesan individual request since the state data will be provided to whicheverSLP node 121-123 with which the SET 130 communicates.

Notably, storing session state data only on the SET 130 presents apotential security risk. For example, the SET 130, when aware of thismechanism, may exploit the stored session state data in various ways.Because the SET 130 holds the only copy of the state data, it would beable to alter the session state data as it chooses. Storing state dataas plain text therefore is not viable. Some form of integrity protectionis necessary. For example, the state data can be integrity protected bya message authentication code (MAC) or, where confidentiality is alsodesirable, a combination of a checksum or hash and encryption.

FIG. 2 is a block diagram showing an illustrative format of state data,in which the state data is encrypted, according to a representativeembodiment.

In the format depicted in FIG. 2, the state data format includes keyidentifier 210 and initialization vector (IV) 220, which are notencrypted, and encrypted portion 230, which includes state data 240 andchecksum 235. The state data 240 is the data needed to identify andcontinue a triggered session. For example, the state data 240 mayinclude the data shown in FIG. 1, such as SET ID 241, client URL 242,and SUPL INIT HMAC 243, which are shown for purposes of illustration.The key identifier 210 is used to identify an encryption key that isstored by all of the SLP nodes 121-123. This allows for the encryptionkey to be changed periodically. The IV 220 is used to establish aninitial state for the cipher. For example, a block cipher, such asAdvanced Encryption Standard (AES), may be used, although other types ofciphers and/or encryption may be incorporated without departing from thescope of the present teachings. Use of a block cipher limits theeffectiveness of some cryptanalysis attacks.

In the encrypted portion 230, the SET ID 241 provides identification ofthe SET 130, such as an IP address or a Mobile Station IntegratedServices Digital Network (MSISDN) number, and the client URL 242provides identification of the location client 110. The checksum 235 iscalculated over the combined state data 240, and prevents the SET 130from modifying the encrypted portion 230. Alternatively, a cryptographichash or hash-based message authentication code (HMAC), such as HMAC-64,may be included, although this is not necessary since the SET ID 241 andthe client URL 242, as well as the other state data 240, are encrypted.With a block size of 128 bits, for example, at most 12 blocks can beenciphered, leaving 26 bits free for the key identifier 210 and the IV220. A 128-bit IV 220 would leave 11 blocks or (176 bytes) for the statedata 240, less the size of the checksum 235, which may require up to 16bits, for example.

FIG. 3 is a block diagram showing an illustrative format of state data,in which the state data is not encrypted, according to anotherrepresentative embodiment.

In the format depicted in FIG. 3, the state data format includesunencrypted state data 340, which may include SET ID 341, client URL342, SUPL INIT HMAC 243, and other data from Table 1, which areunencrypted but otherwise substantially the same as the SET ID 241, theclient URL 242, and the SUPL INIT HMAC 243, discussed above. The statedata format of FIG. 3 further includes an encrypted key identifier 310and HMAC 350. The HMAC 350 is calculated over the combined state data340 and key identifier 310, and provides a message authentication codeusing a cryptographic hash function and corresponding cryptographic key,e.g., identified by the key identifier 310. Because of the HMAC 350, itdoes not matter whether the SET 130 sees the (unencrypted) state data340. That is, as long as the HMAC 350 is generated with an encryptionkey that is known only to the SLP nodes 121-123, the state data cannotbe changed without the SLP nodes 121-123 knowing. In other words,without the key (which is identified by the key identifier 310), the SET130 can see the state data 340, but is unable to generate state thatwould be considered valid by the SLP 120. Again, the key identifier 310may be used to enable rotation of the encryption key.

The encryption approach depicted in FIG. 3 has approximately the samecost in bytes as the encryption approach depicted in FIG. 2, dependingon the hashing algorithm used. For example, the HMAC 350 may use aSecure Hash Algorithm (SHA), such as SHA-1, which is a 160-bit hashfunction, or SHA-256, which is a 256-bit hash function. Fewer bits maybe included at the cost of weakening the assurance that the contents ofthe state data will not be modified.

The SUPL protocol provides the location client 110 the ability to cancela triggered session. For example, the location client 110 may identifythe triggered session using the Request ID shown in Table 1 (which maybe referred to as req_id). The Request ID is created by the SLP 120 andprovided to the location client 110 in the SUPL INIT message sent instep 102 of FIG. 1, so it may be used to store the information necessaryto cancel a request.

More particularly, the SLP 120 may store the SET Identifier (e.g.,identifying the SET 130) in the Request ID, along with parameters thatuniquely identify the triggered session. The Request ID is provided bythe location client 110 to the SLP 120, e.g., in a MLP triggeredlocation reporting stop request (tlrsr) message, when it requests thatthe triggered session be cancelled. Using the SET Identifier, the SLP120 is able to contact the SET 130. A session info query, using a newsession, is sent by the SLP 120 to the SET 130, e.g., in a SUPL INITmessage. In response, to the session info query, the SET 130 sends aSUPL REPORT message that includes information on all the triggeredsessions that are open on the SET 130. The triggered session thatcontains a matching Request ID is then be selected and cancelled.

A limitation involved with storing state data on the SET 130 is that thestate data stored by the SET 130 is immutable. In other words, the statecannot change. Therefore, features such as limiting the number of usesof the triggered session are not possible. This exposes the SLP 120(and/or the location client 110) to denial of service through triggeredreporting. Because the SLP 120 does not have the state data for thetriggered session, it is unable to track repeated reports. The SET 130could generate reports at a high rate, overwhelming SLP 120 or thelocation client 110 with reports, effectively causing a denial ofservice (DOS) attack. The number and frequency of reports is not trackedfor each triggered session. Thus, in various embodiments, the SLP 120may maintain short-lived (and per-node) state to prevent this sort ofDOS attack. Accordingly, the SLP 120 still does not have to maintainlong-lived state, but DOS attacks are limited.

FIG. 4 is a flowchart illustrating a method for establishing andmaintaining a triggered session for location determination of a mobiledevice based on a conditional trigger, according to a representativeembodiment. The process of FIG. 4 may be executed, for example, by oneor more servers corresponding to the SLP nodes 121-123 of the SLP 120,depicted in FIG. 1.

In block S410, the SLP 120 (via one of the SLP nodes 121-123) receives arequest for a triggered session with respect to a mobile device (e.g.,SET 130). The request may be initiated by any of a variety of sources,and received over voice/data communication channels and/or signalingchannels. For example, referring to FIG. 1, the request may be a MLPtriggered location reporting request (tlrr) message received from thelocation client 110. In response, the SLP 120 modifies a session messageto include state data in block S420, and sends a request for a triggersession to the SET 130 in block S430, where the request includes themodified session message. For example, the session message may be a SUPLINIT message having a SlpSessionID parameter, and thus modifying thesession message includes setting free bits of the SlpSessionID parameterto include the state data, as discussed above. In various embodiments,the state data and/or a key identifier associated with the state datamay be encrypted, as discussed above with reference to FIGS. 2 and 3, sothat the state data may not be altered by the SET 130, which is unableto decrypt the state data and/or the key identifier. The request may betransmitted by the SLP 120 over voice/data communication channels and/orsignaling channels.

The SET 130 receives and stores the state data in order to maintainstate for the triggered session. The triggered session includes one ormore conditional triggers that have corresponding trigger events, suchas the SET 130 entering or leaving a specified geographic region,occurrence of a time of day, or the passing of a specified timeinterval. Upon occurrence of a trigger event, the SET 130 generates atriggered message, which may include the identity of the SET 130, thetime of occurrence of the trigger event, and position data indicatingthe location of the SET at the time the trigger event occurs, forexample. As discussed above, the position data may include positioningmeasurement information from which another device (e.g., the SLP 120)can calculate the estimated position of the SET 130, or an actualestimated position of the SET 130 as calculated by the SET 130 itself.For example, when the SET 130 includes a GNSS receiver, the GNSSreceiver locks on to and receives signals from at least four GNSSsatellites. The received signals may include navigation messages, forexample, providing ephemeris data and timing signals, enabling the GNSSreceiver to generate the positioning measurement information.

The triggered message is received from the SET 130 by the SLP 120 inblock S440, e.g., over voice/data communication channels and/orsignaling channels, responsive to the one or more conditional triggers.In block S450, the state data is retrieved from triggered message by theSLP 120. The SLP 120 validates the integrity of the state data when itis received, rejecting any invalid state. When the state data or the keyidentifier is encrypted, the SLP 120 also performs the appropriatedecryption process. Once the SLP 120 has the state data, it retrievesthe position data from the triggered message (or from subsequent SUPLPOS messages) and calculates the position estimate of SET in block S460.The position estimate is then sent to the location client 110 in blockS470.

The various process steps described with reference to FIG. 4 may beperformed by a processing device or server, such as the SLP 120, or whenthe SLP 120 includes clustering, one or more of the SLP nodes 121-123.FIG. 5 is a functional block diagram illustrating such a processingdevice (e.g., indicated for purposes of explanation as SLP nodes 120),which is configured to execute an algorithm and/or process formaintaining session state in a SUPL enabled system during a triggeredsession, according to a representative embodiment. Although the SLP 120is shown and discussed below, it is understood that other servers,computers or nodes, such as each of the SLP nodes 121-123 and/or the SET130, may be configured in a similar manner, at least with respect toprocessing and storage functionality.

The various “parts” shown in the SLP 120 may be physically implementedusing a software-controlled controller or microprocessor, e.g.,processor 521, hard-wired logic circuits, firmware, or a combinationthereof. Also, while the parts are functionally segregated forexplanation purposes, they may be combined variously in any physicalimplementation.

In the depicted embodiment, the SLP 120 includes processor 521, memory522, bus 529 and various interfaces 525-526. The processor 521 isconfigured to execute one or more logical or mathematical algorithms,including maintaining session state in a SUPL enabled system, as well asposition calculation processes, of the embodiments described herein, inconjunction with the memory 522. The processor 521 may also executebasic functionality for controlling geographic location determinationprocesses for locating mobile devices. The processor 521 may beconstructed of any combination of hardware, firmware or softwarearchitectures, and include its own memory (e.g., nonvolatile memory) forstoring executable software/firmware executable code that allows it toperform the various functions. Alternatively, the executable code may bestored in designated memory locations within memory 522, discussedbelow. In an embodiment, the processor 521 may be a central processingunit (CPU), for example, and may execute an operating system.

The memory 522 may be any number, type and combination of external andinternal nonvolatile read only memory (ROM) 523 and volatile randomaccess memory (RAM) 524, and stores various types of information, suchas signals and/or computer programs and software algorithms executableby the processor 521 (and/or other components). As generally indicatedby ROM 523 and RAM 524, the memory 522 may include any number, type andcombination of tangible computer readable storage media, such as a diskdrive, an electrically programmable read-only memory (EPROM), anelectrically erasable and programmable read only memory (EEPROM), a CD,a DVD, a universal serial bus (USB) drive, and the like.

In addition, the SLP 120 includes one or more communication interfaces,indicated by representative communications interface 526, to enablecommunications with one or more components of the wirelesscommunications network 100. For example, the communications interface526 enables communications with mobile devices (e.g., SET 130) or otherGNNC receivers, through base stations or node Bs. In addition, thecommunications interface 526 also enables communicates with varioussources, such as the location client 110. The communications may beprovided to the processor 521 and/or the memory 522 via bus 529. Invarious embodiments, the communication interface 526 includes one ormore types of interfaces, such as wireless or wired Ethernet, TCP, ATM,or MTP, for example. However, the number, types and arrangement ofinterfaces may vary without departing from the scope of the presentteachings.

A user and/or other computers may interact with the SLP 12—using variousinput device(s) through I/O interface 525. The input devices may includea keyboard, key pad, a track ball, a mouse, a touch pad ortouch-sensitive display, and the like. Also, various information may bedisplayed on a display (not shown) through a display interface (notshown), which may include any type of graphical user interface (GUI).

In various embodiments, the process steps depicted FIG. 4 may beincorporated within one or more processing modules of a device, such asthe SLP 120 and/or the SET 130 depicted in FIG. 1. However, the modulesmay be executable by any other server, computer or node having access tothe location client 110 and/or the SET 130, without departing from thescope of the present teachings. The modules may be implemented as anycombination of software, hard-wired logic circuits and/or firmwareconfigured to perform the designated operations. Software modules, inparticular, may include source code written in any of a variety ofcomputing languages, such as C++, C# or Java, and are stored on tangiblecomputer readable storage media, such the computer readable storagemedia discussed above with respect to memory 522, for example.

Generally, in accordance with various embodiments, a location serverestablishes a triggered session with a mobile device at the request of alocation client, so that the mobile device provides triggered messages,which may include the geographic location of the mobile device, inresponse to one or more trigger events. State data is provided by thelocation server to the mobile device via modified session messaging, sothat state is maintained only by the mobile device. For example, freebits in existing fields of a session ID parameter may be used to conveythe state data to the mobile device. The state data is returned to thelocation server in one or more triggered messages, along with thegeographic location of the mobile device and/or measurement informationfrom which the geographic location may be determined. Security of thestate data may be ensured, for example, by encrypting the state dataand/or key identifiers provided to the mobile device.

While specific embodiments are disclosed herein, many variations arepossible, which remain within the concept and scope of the invention.Such variations would become clear after inspection of thespecification, drawings and claims herein. The invention therefore isnot to be restricted except within the scope of the appended claims.

What is claimed is:
 1. A method comprising: transmitting, from a servercomprising one or more computing devices, a request to a Secure UserPlane Location (SUPL) Enable Terminal (SET) over a given communicationchannel to initiate a triggered session, the request comprising asession message, wherein the session message includes state datasufficient to maintain a session state of the triggered session;closing, at the server, the given communication channel after thesession message is received at the SET; clearing, from the server, thestate data from memory of the server in response to the closing, whereinthe SET maintains the only copy of the state data; receiving, at theserver, a triggered message from the SET over another communicationchannel, the triggered message comprising the stored state data; andre-establishing, at the server, the triggered session over the othercommunication channel using the state data received from the SET in thetriggered message.
 2. The method of claim 1, further comprising:calculating, at the server, an estimated position of the SET usingposition data included in the triggered message.
 3. The method of claim1, wherein the triggered message received from the SET comprises one ofa SUPL REPORT message and a SUPL POS INIT message.
 4. The method ofclaim 1, wherein the session message transmitted to the SET comprises anSULP INIT message.
 5. The method of claim 1, further comprisingdetermining, at the server, content of the session message that includesthe state data.
 6. The method of claim 5, wherein the determiningcomprises setting free bits in at least one of a sessionID field and aslpID field of the SlpSessionID parameter of the session message toinclude the state data.
 7. The method of claim 5, wherein determiningcontent of the session message comprises: encrypting the state data,wherein the SET stores the encrypted state data, and is incapable ofdecrypting the encrypted state data.
 8. The method of claim 7, whereinthe session message includes a key identifier that identifies a keyknown only to a SUPL Location Platform (SLP).
 9. The method of claim 7,wherein re-establishing the triggered session comprises decrypting thestate data received in the triggered message.
 10. The method of claim 5,wherein the determining comprises: including a message authenticationcode, wherein the SET stores an unencrypted version of the state dataand message authentication code.
 11. The method of claim 10, wherein thesession message includes a key identifier that identifies a key knownonly to an SUPL Location Platform (SLP).
 12. The method of claim 10,wherein re-establishing the triggered session comprises: employing thekey identifier to identify an encryption key; performing a cryptographichash function using the identified encryption key; and verifying thatthe state data received in the triggered message has not been alteredusing the cryptographic hash function.
 13. The method of claim 1,further comprising: receiving position data from the SET via the othercommunication channel, wherein the position data indicates a location ofthe SET; and setting an estimated position of the SET to the locationindicated in the position data.
 14. The method of claim 13, furthercomprising: receiving a request from a location client to initiate thetriggered session with the SET; and sending the estimated position ofthe SET to the location client.
 15. The method of claim 1, wherein thereceiving and the re-establishing occur at least one hour after theclosing.
 16. A non-transitory computer readable medium having machinereadable instructions, the machine readable instructions comprising: atransmitting module configured to transmit a request to a Secure UserPlane (SUPL) Enabled Terminal (SET) to initiate a triggered session overa given communication channel, the request comprising a session message,wherein the session message includes state data sufficient to maintain asession state of the triggered session; a closing module configured toclose the given communication channel after the session message isreceived by the SET; a clearing module configured to clear the statedata from memory in response to the closing, such that the SET maintainsthe only copy of the state data; a receiving module configured toreceive a triggered message from the SET over another communicationchannel, the triggered message comprising the stored state data; and anidentifying module configured to re-establish the triggered sessionusing the state data received in the triggered message.
 17. Thenon-transitory machine readable medium of claim 16, further comprising:a position module configured to set an estimated position of the SETusing position data included in the triggered message, wherein theposition data characterizes a location of the SET.
 18. Thenon-transitory machine readable medium of claim 16, further comprising:an encrypting module configured to encrypt the state data included inthe session message, wherein the SET stores the encrypted state data,and is incapable of decrypting the encrypted state data.
 19. A methodcomprising: setting free bits of a SlpSessionID parameter in a sessionmessage from a Secure User Plane Location (SULP) Location Platform (SLP)to include state data sufficient to maintain the session state of thetriggered session; transmitting the session message to a SUPL EnabledTerminal (SET) from the SLP to the SET to initiate the triggered sessionover a given communication channel, the SET storing the free bits of theSlpSessionID; closing the given communication channel after the SETreceives the session message; clearing the state data from memory of theSLP in response to the closing, wherein the SET maintains the only copyof the state data; receiving, at the SLP, a SUPL POS INIT message fromthe SET over another communication channel, the SUPL POS INIT messagecomprising the stored state data; and re-establishing, at the SLP, thetriggered session using the stored state data in the SUPL POS NITmessage.
 20. The method of claim 19, further comprising: encrypting, atthe SLP, the state data included in the at least one modified parameter,wherein the SET stores the encrypted state data, and is incapable ofdecrypting the encrypted state data.